docs: send access tokens in the TES tutorials - #135

Please address the comments from this code review:

## Individual Comments

### Comment 1
<location path="docs/tutorials/tes-services/tes-hub/tes-api.sh" line_range="18" />
<code_context>
+tes_curl() {
+  local out code
+  if [[ -n "${TES_TOKEN:-}" ]]; then
+    out="$(curl -sS -w '\n%{http_code}' -H @<(printf 'Authorization: Bearer %s\n' "$TES_TOKEN") "$@")" || return 1
+  else
+    out="$(curl -sS -w '\n%{http_code}' "$@")" || return 1
</code_context>
<issue_to_address>
**Bearer token sent to arbitrary TES URL**

When a user configures `TES_URL` as HTTP or points it at a host they do not trust, `tes_curl` sends `TES_TOKEN` to the URL in `TES_API` without checking its scheme or host, so a user who sets `TES_URL` to an HTTP endpoint or an untrusted HTTPS host exposes the bearer token to that endpoint. The commands-page `curl` examples do the same, allowing the recipient to use the token against the TES service.

Require HTTPS whenever a token is set, and document that `TES_URL` must identify the intended trusted TES service.

Also at `docs/tutorials/tes-services/interactive_services_tes.md:90`, `docs/tutorials/tes-services/interactive_services_tes_commands.md:102`, `docs/tutorials/tes-services/interactive_services_tes_commands.md:217`.
</issue_to_address>

### Comment 2
<location path="docs/tutorials/tes-services/tes-hub/tes-api.sh" line_range="18" />
<code_context>
+tes_curl() {
+  local out code
+  if [[ -n "${TES_TOKEN:-}" ]]; then
+    out="$(curl -sS -w '\n%{http_code}' -H @<(printf 'Authorization: Bearer %s\n' "$TES_TOKEN") "$@")" || return 1
+  else
+    out="$(curl -sS -w '\n%{http_code}' "$@")" || return 1
</code_context>
<issue_to_address>
**Verbose curl logs bearer tokens**

When the user's curl configuration enables verbose output, `curl` reads its user config by default, so a config that enables verbose output makes these requests print the outgoing `Authorization` header to stderr. The keep-alive loops redirect stderr to `watch.log`, persisting the token there.

Disable curl configuration for token-bearing requests (using `-q` as curl's first option), including the commands-page examples.

Also at `docs/tutorials/tes-services/tes-hub/tes-service.sh:192`, `docs/tutorials/tes-services/omop-tesk/omop-tesk-fi.sh:215`, `docs/tutorials/tes-services/interactive_services_tes_commands.md:102`, `docs/tutorials/tes-services/interactive_services_tes_commands.md:217`.
</issue_to_address>

### Comment 3
<location path="docs/tutorials/tes-services/tes-hub/tes-api.sh" line_range="11" />
<code_context>
+
+# The token stays a shell variable: not exported, so that no child process (such as the
+# hub, which runs for days) gets it. The launchers pass it to their keep-alive loop only.
+if [[ -n "${TES_TOKEN:-}" ]]; then export -n TES_TOKEN; fi
+
+# tes_curl <curl arguments>: prints the body of a 2xx answer. Otherwise prints why to
</code_context>
<issue_to_address>
**Shell tracing exposes the token**

When the Bash environment enables xtrace, such as through exported `SHELLOPTS` or `BASH_ENV`, bash xtrace prints expanded command arguments, including the token in the `TES_TOKEN` test and `printf` command; it also traces the token-bearing keep-alive launch assignment. The loop launch redirects stderr to `watch.log`, so the token is written to disk.

Disable xtrace before any token-bearing expansion or loop-launch assignment, and restore it only after those sensitive operations.

Also at `docs/tutorials/tes-services/tes-hub/tes-api.sh:18`, `docs/tutorials/tes-services/tes-hub/tes-service.sh:192`, `docs/tutorials/tes-services/omop-tesk/omop-tesk-fi.sh:215`.
</issue_to_address>

### Comment 4
<location path="docs/tutorials/tes-services/tes-hub/tes-service.sh" line_range="60" />
<code_context>

 die() { echo "ERROR: $*" >&2; exit 1; }
+# shellcheck source=SCRIPTDIR/tes-api.sh
+source "$HERE/tes-api.sh"
 json_get() { python3 -c 'import json,sys; d=json.load(sys.stdin); print(eval(sys.argv[1], {"d": d}))' "$1"; }
 ID_FILE="$STATE_DIR/task"
</code_context>
<issue_to_address>
**Child processes inherit the token**

When the user exports `TES_TOKEN` as instructed, the launchers run commands such as `mkdir`, `chmod`, and `sed` before sourcing `tes-api.sh`; those child processes inherit the bearer token before `export -n` runs, exposing it to programs that do not need it.

Un-export `TES_TOKEN` before launching any child process, while explicitly passing it only to the keep-alive loop.

Also at `docs/tutorials/tes-services/omop-tesk/omop-tesk-fi.sh:74`, `docs/tutorials/tes-services/tes-hub/tes-api.sh:11`.
</issue_to_address>

### Comment 5
<location path="docs/tutorials/tes-services/tes-hub/tes-service.sh" line_range="141" />
<code_context>
 cmd_cancel() {
   local id; id="$(task_id)"
-  [[ -n "$id" ]] && curl -fsS -m 30 -X POST "$TES_API/tasks/$id:cancel" >/dev/null && echo "canceled $id" || true
+  [[ -n "$id" ]] && tes_curl -m 30 -X POST "$TES_API/tasks/$id:cancel" >/dev/null && echo "canceled $id" || true
 }

</code_context>
<issue_to_address>
**Failed cancellations appear successful**

When the task-list check succeeds but a later cancel request fails, `cmd_cancel` and `cancel_role` suppress `tes_curl` failures with `|| true`, so `down` skips its uncanceled-task warning and exits successfully while tasks remain running; callers see cancellation as successful.

Propagate cancellation failures and have `down` emit its warning when cancellation fails.

Also at `docs/tutorials/tes-services/omop-tesk/omop-tesk-fi.sh:157-158`, `docs/tutorials/tes-services/omop-tesk/omop-tesk-fi.sh:254-255`, `docs/tutorials/tes-services/tes-hub/tes-service.sh:142`, `docs/tutorials/tes-services/tes-hub/tes-service.sh:219-220`.
</issue_to_address>

### Comment 6
<location path="docs/tutorials/tes-services/tes-hub/tes-service.sh" line_range="234" />
<code_context>
   down)     cmd_down ;;
-  restart)  cmd_down; cmd_up ;;
+  restart)  tes_check || die "cannot use the TES at $TES_URL"; cmd_down; cmd_up ;;
   setup)    cmd_setup ;;
   submit)   lock; for r in $(roles_arg "${2:-}"); do submit_role "$r"; done; unlock ;;
   status)   cmd_status ;;
</code_context>
<issue_to_address>
**Restart leaves the service inaccessible**

When TES access fails after the restart preflight, `cmd_down` locks out the old tasks before `cmd_up` checks TES access; `current_state` or `role_state` turns that error into `UNREACHABLE`, which `up` treats as still running, so it starts a loop without replacement tasks and leaves the service inaccessible.

Make restart abort without locking out existing tasks when TES access fails, and make `cmd_up` fail rather than treat TES errors as a running state.

Also at `docs/tutorials/tes-services/omop-tesk/omop-tesk-fi.sh:332`.
</issue_to_address>

### Comment 7
<location path="docs/tutorials/tes-services/tes-hub/tes-service.sh" line_range="190" />
<code_context>
   local state i; state="$(current_state)"
   if is_done "$state"; then cmd_submit; else echo "task $(task_id) is $state, not resubmitting"; fi
+  # The loop keeps the token it started with: replace it, so that it gets the current one.
+  if watching && [[ -n "${TES_TOKEN:-}" ]]; then stop_watch; fi
   if ! watching; then
-    setsid -f "$HERE/tes-service.sh" "$DIR" watch >> "$STATE_DIR/watch.log" 2>&1 < /dev/null
</code_context>
<issue_to_address>
**Orphan loops keep submitting tasks**

When two token-bearing `up` invocations overlap while replacing or starting a keep-alive loop, both invocations act on stale watcher state and can launch duplicate loops with different tokens, overwriting the shared PID file; `down` then stops only the recorded loop, leaving an orphan able to submit tasks.

Serialize watcher stop-and-start operations and ensure only one keep-alive loop can run.

Also at `docs/tutorials/tes-services/tes-hub/tes-service.sh:192`, `docs/tutorials/tes-services/omop-tesk/omop-tesk-fi.sh:213-215`.
</issue_to_address>

### Comment 8
<location path="docs/tutorials/tes-services/tes-hub/tes-service.sh" line_range="227" />
<code_context>
+# locks the pods out first, and needs the TES only to cancel.
+case "${1:-}" in
+  up|submit|logs|cancel|selftest) tes_check || die "cannot use the TES at $TES_URL" ;;
+  status) tes_check || true ;;
+esac
+
</code_context>
<issue_to_address>
**Status succeeds without TES access**

When the TES rejects the task-list check because the token is missing, invalid, or expired, `status` ignores the `tes_check` failure with `|| true` and continues querying state, reports `UNREACHABLE`, then exits successfully; shell callers see a successful check despite the incomplete status report.

Make `status` return failure when `tes_check` fails, including in the OMOP launcher.

Also at `docs/tutorials/tes-services/omop-tesk/omop-tesk-fi.sh:326`, `docs/tutorials/tes-services/tes-hub/tes-service.sh:199`.
</issue_to_address>

### Comment 9
<location path="docs/tutorials/tes-services/omop-tesk/omop-tesk-fi.sh" line_range="255" />
<code_context>
-  local r; for r in "${ROLES[@]}"; do cancel_role "$r"; done
+  local r
+  if tes_check; then for r in "${ROLES[@]}"; do cancel_role "$r"; done
+  else echo "WARNING: tasks not canceled; run: $0 cancel" >&2; fi
   unlock
 }
</code_context>
<issue_to_address>
**Down continues after rejection**

The issue asks commands to fail early on 401 or 403. Down checks the TES only after stopping the loop and locking out tasks, then warns and continues; the single-container launcher follows the same behavior.
</issue_to_address>

### Comment 10
<location path="docs/tutorials/tes-services/tes-hub/tes-api.sh" line_range="18-22" />
<code_context>
+tes_curl() {
+  local out code
+  if [[ -n "${TES_TOKEN:-}" ]]; then
+    out="$(curl -sS -w '\n%{http_code}' -H @<(printf 'Authorization: Bearer %s\n' "$TES_TOKEN") "$@")" || return 1
+  else
+    out="$(curl -sS -w '\n%{http_code}' "$@")" || return 1
+  fi
+  code="${out##*$'\n'}"; out="${out%$'\n'*}"
+  case "$code" in
+    2??) printf '%s\n' "$out" ;;
</code_context>
<issue_to_address>
**Large task logs exhaust memory**

When a TES FULL response contains very large task logs, `tes_curl` captures the entire response in `out` before printing it; `logs` and `selftest` then parse FULL task responses, so a sufficiently large task log makes the shell and parser hold large copies at once and can exhaust VM memory before the output is produced.

Avoid buffering successful response bodies in `tes_curl`; preserve streaming while separately checking the HTTP status.
</issue_to_address>

### Comment 11
<location path="docs/tutorials/tes-services/interactive_services_tes.md" line_range="89" />
<code_context>
+- A TES service whose tasks can make outbound HTTPS connections, and an
+  access token for it if it needs one (see [Get an access
+  token](#get-an-access-token)). The scripts use the TESK of ELIXIR-FI
+  without tokens (`https://csc-tesk-noauth.rahtiapp.fi`). To use another
+  service, set `TES_URL`.
+
</code_context>
<issue_to_address>
**Default still described as tokenless**

The issue asks to remove notes that the default instance is unauthenticated. The prerequisites still describe the default TESK as “without tokens,” which conveys that same point.
</issue_to_address>